Turnbull China Bikeride/Turnbull China Bikeride - Disc 1.iso/ARGONET/PD/EMULATOR/D64IMAGE.ZIP/!D64FS/!Help

Text File | 1997-03-21 | 7KB | 174 lines

D64FS - An Image Filing System for C64 disc images (V0.00)
==========================================================



Now with a native RISC OS C64-Emulator available there's the question
of how to get software for the emulator. The most common source data
are files in T64 and D64 format. The former are tape archive files
with a very simple structure, used mainly for programs that don't
load any additional files after startup. The later are byte-for-byte
copies of VC1541 disc images used mostly for programs that do load
additional files. In contrast to T64 archives extracting files from
a D64 disc image is considerably more complicated than 10 seconds
worth of editing. Therefore I chose to write this image filing system
which does the job for you and also shows why a modular OS is a
really good idea.

All you have to do is start the module (type "help d64fs" at the
command line to see if it's active) and give the disc images the
file type &164 (D64Image). This filetype, the module name and its star
commands are all registered at Acorn, therefore this release is
official.
That done you merely have to double-click on the image to open a
filer window with its contents. Accessing files is considerably
slower than with native RISC OS files. One reason for this is that
the data blocks contained in a file can be spread over a large area of
the image file. The other one is that C64 disc images don't give the
_exact_ size of a file with its directory entry (only the number of
blocks which doesn't even have to be correct). RISC OS has to know
the exact size of a file _before_ loading, however, so when loading
a file it has to be scanned first; that means the file will have to
be traversed twice, hence the delay.
Of course I might have claimed lots of RMA space for buffering but I
decided against this on the grounds that D64FS is not supposed to be
a high performance FS for everyday use but a convenient and RISC OS
compliant way of accessing this type of data. If you're doing lots
of operations on a disc image you can always speed things up a lot
by copying it into a RAM disc.

D64FS is read _and write_ so you can also copy stuff into disc images
or create new ones. The disc image size is not fixed to the standard
35 tracks but may be any value between 18 and 40. If the number of
tracks exceeds 35 the format used for the BAM will be that of Dolphin
DOS (that means essentially that the BAM entries for tracks 36-40
start in Block 18,0 at offset &ac).

Discs aren't recognized if the image is less than 18 "tracks" long
(no directory track) or the first two bytes in block 18,0 are not 18,1.
I used to check for the full 18,1,65,0 as given in the VC1541 manual
but discarded that again when I came across disc images that didn't
conform with this.


Name conversions:
-----------------

This is a bit tricky since the character sets used by RISC OS and by
the C64 are rather different. You shouldn't experience any trouble if
you stick to non-accented (top bit clear) characters (with the exception
of char #152 and char #156 which are OK), best to keep them lower case as
well. Some CBM-characters are translated to the same RISC OS characters,
however, so there might be name clashes (for instance `.' and <arrow left>
are both translated to `_'). So far I haven't experienced any trouble but
be warned that there may be.


Filetype conversions:
---------------------

This is even trickier. The C64 knows 5 different filetypes, namely DEL,
SEQ, PRG, USR and REL. I don't think using up 5 RISC OS filetypes just
for this is a good idea and besides hardly anything but PRG is used
anyway (with the exception of DEL which is only used on empty files,
though). So I chose the following mappings:

DEL <--> &ffe    Command
SEQ <--> &ffd    Data
PRG <--> &064    (the filetype used by !Breadbox)
USR <--> &ffc    Utility
REL <--> &fff    Text

If you copy a RISC OS file with a different filetype into a disc image
its type will default to PRG (&064).



Command Line options:
=====================

D64FS offers two commands:

D64create [-t x] <filename> <discname,id>
    This command creates a disc image file named <filename> with
    x tracks (x between 18 and 40, default 35). The disc name (up
    to 18 chars) and id (2 chars) are stored in the image; everyone
    who ever worked with a C64 will know what they are.

D64tidy [-v -r -c] <filename>
    This does various operations on a C64 image file. Be warned
    that these operations might take some time (very much dependent
    on what kind of device the image is stored on - this should be
    a harddisc or a RAM disc). The aim of these operations is mostly
    to discard any unused space and thus make the image file compress
    better. Be warned that if the disc contains information not stored
    in files this data will be lost irretrievably (-c,-r) or exposed
    to overwriting (-v). Neither problem can arise with images created
    by D64FS. When in doubt don't tidy up the disc!

    -v    Validate disc. That means update the BAM (block allocation
        map), i.e. scan all files to determine which blocks are
        used and which are not and write the result on the image.
        This operation may be used if the BAM has been corrupted
        for some reason. If the disc image contains data not stored
        in files a following write-operation might overwrite it!

    -r    Clear unused rest of partially filled blocks. The last
        block of a file is usually not filled to the end. The data
        contained in the rest of the block has no purpose whatsoever
        if the disc image contains only files and thus may be deleted
        (i.e. overwritten with 0s).

    -c    Clear unused blocks. The most dangerous operation which will
        fill entire blocks with 0s if they're marked unused in the
        BAM. If the disc image contains data not stored in files
        or a corrupt BAM data will be lost permanently so handle
        with care!

    If you specify more than one switch the operations will be executed
    in the following order: first -v and/or -r in parallel, then -c.
    E.g. -v -c will first update the BAM and then clear unused blocks.




LIMITATIONS:
------------

To keep down the workspace size the maximum number of open D64Image files is
currently set to 32. If the module complains about there being too many open
images you'll have to close some of them, for instance by typing *close at
the CLI (which closes all open files on the current FS).
The number of open files within D64 images is limited to 32 as well. This
should usually not be a problem, though, since there's hardly ever more than
one open (unless some program messed up).



KNOWN BUGS:
-----------

1) Files with zero length will take up one data block nonetheless. But that's
   not really a bug since files like these are pretty senseless anyway.

2) None I found so far (...and are still present...)





LEGAL ISSUES and CONTACT:
=========================

This program is Videoware. For an explanation of what that means and how to
contact me read the file "VIDEOWARE".




Happy nostalgia,



Andreas Dehmel, March 97.